In wireless environments such as GPRS (General Packet Radio Service), retransmission timers are known to often expire spuriously, triggering an unnecessary retransmission of one or more data packets even when there has been no actual loss of transmitted data. Such “spurious timeouts,” as they are known (also referred to as an “STO”), are generally attributable to limitations in a Transmission Control Protocol (hereafter “TCP”) stack.
Spurious timeouts in wireless networks have various causes including, e.g. the emergence of data packets having higher transmission priority competing for transmission bandwidth, resulting in a spurious retransmission timeout; a persistent reliable wireless link layer repeatedly retransmitting a data packet over a poor radio connection several times to cause a TCP sending host time-out; or a receiving host being unable to send an acknowledgement message (hereafter “ACK”) to a sending host in a timely manner due to a busy reverse channel.
In the TCP stack, the MSS (“maximum segment size”) indicates the maximum amount of data (in bytes) that a sending host is able to send to a receiving host in a single packet, or segment. Generally, for the sake of efficiency, a sending host sends data packets in accordance with MSS. A TCP window (hereafter “window”) refers to the amount of data that a sending host may send before receiving an acknowledgment (also referred to as an “ACK”) regarding the data sent from the receiving host.
ACK is a communication code sent from the receiving host to the sending host to acknowledge receipt of transmitted data. Further, ACK may be transmitted to the sending host from the receiving host after every TCP segment of data is received. Alternatively, ACK may be selectively transmitted to the sending host from the receiving host if out-of-order data packets are received. The received data packets are reported in extended TCP header options referred to as Selective Acknowledge (hereafter “SACK”) blocks. Regardless, TCP is unable to distinguish whether ACK or SACK is generated in response to an originally transmitted segment of data or a retransmitted segment of data.
Typically, upon an occurrence of a timeout, a TCP stack defaults to a retransmission of an entire window's worth of data which has not been acknowledged. But, as stated above, not all timeouts are caused by data loss. Therefore, the automatic retransmission may lead to bandwidth being unnecessarily devoted to retransmission of data that has already been successfully received. Consequently, the integrity of a network connection is diminished.
Such automatic retransmission of TCP segments of data may violate the “packet conservation principle,” which states that data should not be introduced to a network until previously transmitted data has been acknowledged as having been received or has been confirmed as having been lost. Clearly, any automatic retransmission of TCP segments after a spurious timeout is incompatible with the packet conservation principle.